The design of the user interface evolved as the design and implementation of the project progressed. To get to its final design it has been refactored many times in order to include only facilities that were needed.

\subsection{Main window}
The main window is central to the user interface, and as a result was subject to many design revisions. This section goes through the various design revisions, showing the initial design, significant revisions, and finishing with the final design.

The design process began with each member of the team creating a paper prototype in order to demonstrate their view of how the main window should look. These prototypes all contained the necessary elements to fulfil the requirements of the project. Each of these prototypes was then reviewed by the team and the team supervisor, who gave feedback on them. As a result of this, a final paper prototype which incorporated the best features of the individual paper prototypes was created.

The final prototype contained the following primary design components:
\begin{itemize}
\item One main window which will contain the contact list and both the message box and chat log.
\item A file menu for system options such as log out, and a user menu for user preferences including changing the window’s colour.
\item Buttons on the main window that will allow the user to stylise their messages.
\item A log-in window which would take the user to the main window, after logging in successfully.
\end{itemize}

We will now discuss these design components in further detail.

These features were based on the conclusion that a user would find it inconvenient to have multiple windows open at once. It was decided that it would be easier and more intuitive to allow a user to switch between all conversations within a single window. This type of layout can be seen within the text instant messaging component of Skype, and the team agreed that this was an intuitive layout. Our experience of using existing instant messaging systems shaped how we chose to design our interface.

The main window is responsible for the majority of the system’s functionality, and is central to the user interface. It had to be intuitive and user friendly in order to allow novice users to easily use the system. In addition, it had to allow the user to get maximal functionality from the system with minimal learning needed. As most users, novice or expert, would be familiar with existing instant messaging systems, our system adopts design elements used in these systems. This reduces the learning curve of our system.

The chat log and message box are represented by two boxes on the right of the window. This layout is typical of most existing instant messaging systems. As there are two types of conversation that a user can participate in, user-to-user or chatroom-based, each had to be represented. Each conversation would be listed in the ``Active Conversations’’ list. The contact list, channel list and active conversations list are on the right of the window, contained in tabs. This means that a user is able to quickly find this information. without cluttering the window. 

A feature in Windows Live Messenger which each team member found appealing was the ability to click on the user’s username causing a contextual menu to appear. This was incorporated into our design and placed above the contact list. Another feature adopted from Window Live Messenger is buttons below the message box which allow the user to stylise their message and add emoticons to it.

Once the above design decisions had been made, the mock-up shown in figure 5.2 was developed.
\begin{figure}[ht!]
	\centering	
	
		\includegraphics[scale=0.50]{images/Interface_Design.jpg}
	    \caption{GUI wireframe}
	    \end{figure}
	
Using the NetBeans IDE’s GUI development tool, the design shown in figure 5.3 was produced in order to show how complex it would be to implement the design.

	\begin{figure}[ht!]
		\centering
		\includegraphics[scale=0.40]{images/proto.png}
	    \caption{GUI prototype}
	    \end{figure}

We chose to implement the user interface using Java Swing, without the use of an interface builder. This was to allow a full understanding of the inner workings of the system, and it would make integrating it with the rest of the system simpler. 

We began the GUI implementation process by implementing the main window. However, due to our inexperience with Java Swing, and the system look and feel of Linux, the first draft of the main window looked as shown in figure 5.5.
\begin{figure}[ht!]
	\centering
		\includegraphics[scale=0.45]{images/oldmain.png}
	    \caption{Main window (first revision)}
	    \end{figure}

		\begin{figure}[ht!]
			\centering
				\includegraphics[scale=0.45]{images/main_one.png}
			    \caption{Main window (second revision)}
			    \end{figure}			
While this closely reflects the design prototypes described, there are clearly issues which resulted from the implementation process. In Java Swing. in order to position elements on the screen a layout has to be chosen. At this stage, the layout in use was a combination of flow and box layouts. These where used as they where the easiest to implement. With the use of these layouts came the constraints associated with them. This is that the components within them are a fixed size and cannot be dynamically changed. This meant that when the window was re-sized the components within it did not change. This made the UI look primitive and unprofessional.

In order to correct this, a different layout had to be used, and we selected the grid bag layout. This layout is more difficult to implement correctly, as it takes specific coordinates and each component has a weight. However one of the main benefits of a grid bag layout is that when a window is re-sized it automatically re-sizes the components within it. After this layout had been adopted, the components had been moved slightly giving it a different appearance. Also, due to our increase of Java Swing knowledge and the introduction of a different look and feel to the window, it appeared less primitive than our initial efforts. Figure 5.5 shows how this revision looked.
	
As the GUI implementation was integrated with the client code, the interface layout changed again. This was due to the requirement that the main window would have to look different once a user logs in, as there would be no chat log or message box. This is because they would not participating in any channels at this stage. The user interface was changed so that when a user logs in they are only presented with their contact list; once they click on the user they wish to talk to the chat log and message box appear. Once this functionality had been implemented the main window had changed to it final design which is depicted in figure 5.6.

\begin{figure}[ht!]
	\centering
		\includegraphics[scale=0.50]{images/main_two.png}
	    \caption{Main window (final revision)}
	    \end{figure}

\subsection{Registration window}

When deciding on the initial design of the registration window we were mainly focused on the simplicity of the window.
As the registration window would only be used comparatively rarely (and did not incorporate any major functionality) we
all agreed on a minimalist design for it. The prototype we created looked as shown in figure 5.7.

\begin{figure}[ht!]
	\centering
	\includegraphics[scale=0.50]{images/registrationWindow.png}
    \caption{Registration window prototype}
    \end{figure}

We needed to use two input boxes to obtain the correct username. The second input box was used to validate that there were no errors, such as spelling, in the username provided in the first input field. We used same method to obtain and validate the user’s password.

Pressing the cancel button should send user back to the login window while pressing the submit button would validate the data submitted and would either send the user back to the login window or it would allow the user to fill in the form again with the correct data.

We adopted the landscape orientation of the registration window as we thought it is clearer way to display labels and input field in such a way.

The initial design of the registration window did not change throughout the implementation process. The final design is shown in figure 5.8.

\begin{figure}[ht!]
	\centering
	\includegraphics[scale=0.50]{images/regFinal.png}
    \caption{Final registration window}
    \end{figure}
\subsection{Login window}

When creating a prototype of the login window, again, we were focused on the simplicity and clarity of the page as its only purpose was to navigate the user to either the main window or to the registration window. For this reason we agreed to have the login window have the same dimensions and orientation as the registration window.
We realise that majority of instant messaging systems, including Skype and Windows Live Messenger use the portrait orientation for their login windows, where the window has a greater height but is smaller width. However, we opted for the landscape orientation to keep the login and registration windows consistent.

The prototype for the login window was as shown in figure 5.10.

\begin{figure}[ht!]
	\centering
	\includegraphics[scale=0.50]{images/loginFirst.png}
    \caption{Prototype login window}
    \end{figure}

However, as we progressed with the implementation we wanted to add a big logo of our system to the login window. In order to accommodate the logo we changed the window layout to the design shown in figure 5.11.

\begin{figure}[ht!]
	\centering
	\includegraphics[scale=0.50]{images/loginFinal.png}
    \caption{Final login window}
    \end{figure}

\subsection{Other windows}

There are also other windows that we made in order to fulfil the \textit{must have} requirements of the instant messaging system. However, these windows do not describe any significant design choices and are self-documenting, providing functionality as expected. The other windows include the add users, upload avatar and user options windows. These are not documented here for brevity.
